home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000478_the_MIME point of view, an NNTP client and server have.msg < prev    next >
Text File  |  1994-01-24  |  2KB  |  62 lines
  1. an implicit agreement that the entity going across the
  2. wire has a content-transfer-encoding of 7bit.
  3.  
  4. This allows them to use the dot-on-a-line-by-iteself technique to
  5. terminate the entitiy.
  6.  
  7. They also share assumptions about the content-type as
  8. a separate issue. The client assumes the response to an
  9. ARTICLE command is a message/rfc822 entity, while the
  10. response to a BODY command is text/plain.
  11.  
  12. So we'll start by throwing out the 7bit restriction and
  13. assuming binary content transfer encoding. Then we need
  14. a new way to terminate entities. It would be nice to
  15. just stick the bytecount in the status message, and then
  16. blast the entity across.
  17.  
  18. But HTTP includes a format negociation such that the client
  19. doesn't know the content-type of the returned data
  20. until it comes back. The easy way around that is to _enclose_
  21. all entities in message/rfc822 entities, using the
  22. Content-Type header.
  23.  
  24. So the server would have to 
  25. 1) compute the headers to enclose the entity in a message
  26. 2) compute the length of the new entity (headers + body)
  27. 3) send a status message with that bytecount, and finally
  28. 4) send the headers and the body entity.
  29.  
  30. Note that in step 2, everybody has to be consistent about
  31. the fact that newlines count as _2_ characters: CR and LF.
  32.  
  33. The the client has to
  34.  
  35. 1) read the status message and extract the bytecount
  36. 2) slurp up that many bytes
  37. 3) find the blank line that separates the header from the body
  38. 4) parse the content-type out of the headers
  39. 5) process the body based on the bytecount
  40.  
  41. That's why I ended up mixing the two levels of protocol
  42. (message/rfc822 headers and HTTP+ status messages.) It would
  43. be easier for the server to:
  44.  
  45. 1) send a status message indicating binary transport (but no bytecount)
  46. 2) print the enclosing headers as they're computed
  47. 3) print one more header that has the bytecount of the body
  48. 4) print a blank line separating the header from the body
  49. 5) blast bytecount octets of data over the wire
  50.  
  51. The the client just does:
  52.  
  53. 1) read and parse nice 7bit headers, one at a time.
  54. 2) when you get to a blank line, you know the bytecount and
  55.    the content-type of the message.
  56. 3) slurp up bytecount bytes of data
  57. 4) process it according to content-type.
  58.  
  59. It is somewhat intertwingled, but I still kinda like it.
  60.  
  61. Dan
  62.